In a component-based business data processing environment, there are typically mixtures of transactional and non-transactional data processing activities in a system at any one time. These transactional and non-transactional activities may have complex relationships and interdependencies, and the management of these relationships and interdependencies is difficult and time-consuming for the system designer and programmer.
The term “transactional” is used in the field of data processing to refer to the processing of a piece of data processing work that may be characterised as having a necessary unity. For example, the data processing task of processing a cash withdrawal from an automated teller machine has several elements, but all must take place for the transaction to be completed. The user's identity must be verified, the cash must be issued, and the user's account must be updated to reflect the new balance after the withdrawal, and so on. If the machine runs out of cash or suffers some other failure, so that the withdrawal does not take place, the user's account must not be updated, or, if it has already been updated before the point of failure, the update must be cancelled so that the account returns to its previous state.
Thus, in the field of transaction processing, transactions are generally required to have what are known as the ACID properties. ACID is an acronym representing the four transaction properties of: Atomicity, Consistency, Isolation and Durability. Atomicity requires that all the operations of the transaction must occur or none must occur. Consistency requires a transaction to maintain the consistency of the database. Isolation requires a transaction not to read the intermediate results of another transaction. Durability requires the results of a committed transaction to be made permanent. For background information on the ACID properties, see Transaction Processing: Concepts and Techniques, J. Gray and A. Reuter.
In a conventional transaction having the ACID properties, the outcome of the transaction (whether it is committed or rolled back) is determined by collecting a set of “votes” or requests from the application using the transaction and the resources (or the resource-owning applications) that are involved in the transaction. In conventional transaction processing environments, these functions are managed by a syncpoint (synchronization point) manager or a recovery manager: a specialised program element designed to gather the “votes” or requests of the participants in the transaction and to act upon them according to some fixed, system- or application-wide rule. This function is clearly limited in that the choices available may be characterized as “go or no-go”, commit or rollback. This is appropriate in the unitary ACID transaction environment.
Clearly, however, there exist more complex business environments requiring characteristics other than those of this simple, unitary transaction model, and these are the subject of continuing study and research. For background information on more complex transaction environments, see Database Transaction Models, Ahmed K. Elmagarmid, ed., and Advanced Transaction Models and Architectures, Jajodia and Kerschberg, eds. Examples taken from real life include, for example, the booking of a vacation, which may involve multiple transactions to book flights and hire cars, reserve hotel rooms, and so on. In such cases, the simple model of a transaction that either works completely or fails completely may not be the best model. It may be more desirable to have some flexibility within the transaction semantics to permit partial successes and failures, to continue one provisional booking while reversing-out another, and so on. At the same time, if such an extended transaction is likely to take a long time to process, it is not appropriate that the transaction should hold the resource locks that are used to maintain data integrity for that long processing time.
In implementing such “nested” transaction structures, the resources also require some form of provisional decision from the transaction user application and from any nested transactions, before they determine their “votes” to contribute to a final outcome.
Large enterprise applications implemented using an Online Transaction Processing (OLTP) system typically use a number of individual ACID transactions to implement a function that the business regards as a complex, but coherent update to business data. It is not possible simply to implement the business transaction as a single ACID transaction because of data and resource sharing requirements in the OLTP environment. Within such a structure, there is still some equivalent of the syncpoint or recovery manager of the conventional environment. Its capabilities, however, must be extended to permit more flexible processing than is allowed for by the simple “commit or rollback” model of the conventional environment.
A further layer of difficulty in managing transactions is created as the trend continues towards the automated deployment of flexible data-processing components in response to high-level abstract models of business processes. One such environment is that described in Enterprise Java Beans Technology, by Anne Thomas (published by Patricia Seybold Group). In such an environment, the degree of abstraction of the process of combining flexible components into a real-world runtime information processing system renders the problem of the detailed control of individual transactions and transaction elements, with all their relationships with heterogeneous resources, extremely difficult.
Thus, in a traditional ACID transaction, the outcome of the transaction (whether the transaction is committed or rolled-back) is determined by collecting a set of votes or requests from the user of the transaction and the resources involved in that transaction. The rule for determining the overall outcome in a traditional ACID transaction is fixed. Once the outcome is decided all the resources and the user of the transaction are informed of the outcome. The fixed nature of this structure is an inhibitor to the development of more flexible environments that reflect real-world processing possibilities.